In the 3GPP project for cellular wireless systems, a mechanism which has as one of its purposes save battery time in user terminals will be introduced, the mechanism being referred to as Discontinuous Reception or DRX.
By means of the DRX mechanism, a user terminal will be able to turn on and off radio resources for a certain amount of time, based on configured parameters and specified rules.
As an example of a DRX mechanism, mention might be made of the so called Continuous Packet Connectivity mechanism, CPC, for WCDMA systems, in which a DRX scheme is specified. According to this scheme, a user terminal initiates continuous usage of its radio resources (continuous reception) as soon as it receives data during a non-DRX period, and resumes a DRX state based on a “timeout” following a period in time during which no data is received.
In 3G systems, as in many other wireless cellular systems, there is a controlling node, in 3G referred to as eNodeB, which has as one of its purposes to control traffic to and from user terminals within a certain area, a cell, in the system. In order for a DRX mechanism to function properly, a set of clear rules are needed to enable the eNodeBs of the system to determine, at all times, the state of “their” user terminals with respect to DRX, i.e. DRX or not.
In LTE systems, there can mainly be two kinds of traffic, real time traffic and non real-time traffic, the latter usually being so called best effort traffic.
For cases of mixed traffic, i.e. cases in which both non real-time (for example “best effort”) flows and real-time flows may be active concurrently, it may with present solutions be difficult for user terminals to have DRX periods, and also to give such periods a suitable duration, a problem which in part is caused by a current approach which is to let a user terminal assume the DRX state based on the characteristics of the traffic.
The approach of deriving a DRX period based on the traffic characteristics or pattern may be suited for non real-time traffic, but it is unclear how well it can be applied to real-time traffic such as VoIP, or to the combination of both, i.e. for mixed traffic. This is particularly relevant as DRX schemes are per UE, and not per Radio Access Bearer, RAB, or per Radio Bearer, RB.
In summary, it can be said that with existing solutions to DRX periods in mixed traffic systems, a problem is that those solutions do not take into account the characteristics of the services in the mixed scenario. In other words, current solutions may not work well when traffic with varying characteristics (real time/non real time) will be active concurrently for one and the same UE.
One possible approach might be to use a scheme that satisfies the real-time traffic delay requirements, which are more stringent than for the non real-time traffic. The eNodeB could, in such a scheme, signal explicitly to the UE e.g. using MAC indications, to change the DRX state or “to be awake” for some “on-duration” period until both the real-time and the non real-time data have been is received, following which the UE could resume DRX by means of an explicit signalling, or autonomously.
However, the purpose of the periodic DRX pattern is quite different between real-time services and best effort services; for the former, it is meant to match the generation of application data (e.g. encoded speech generated at a 20 ms boundary), while for the latter it is meant to provide an upper boundary for the additional delay that best effort data may incur due to DRX.
This means that using only the real-time DRX scheme for mixed traffic could either interfere with how well the periodic wake up of the UE would match the application sending rate, or it might bring about short DRX periods most of the time, even if very little non real-time data is sent. It could also contribute to increased jitter for the real-time flow, which is obviously not a desirable characteristic.